Temporal reasoning refers to Oracle Policy Modeling's ability to reason with rulebase attributes or outcomes whose values change over time. Rules written in Oracle Policy Modeling are thus time-aware, operating simultaneously both at a specific point in time (eg the time at which you run an investigation, or some specific point in the past or future), as well as across time periods (eg 'in the last three months', or 'until the person's 18th birthday').
When analyzing potential rulebase source material, you should take particular note of rules, data or circumstances that may change over time. Oracle Policy Modeling's temporal reasoning functionality may be the ideal choice for modeling situations that suggest changeability. Using temporal reasoning functions, even in some situations that could be modeled without them, can considerably reduce the effort needed both to write the rules and to maintain them in the future.
How conclusions can change over time
What kinds of temporal variation can Oracle Policy Modeling deal with?
Temporal reasoning and areas of change
What does temporal reasoning offer?
When to use temporal reasoning
A worked example of temporal reasoning
All attributes have a value. However, when you view a value (eg using the debugger or a decision report), you are only seeing the value of the attribute at a particular point in time (eg the current time, or 'the date of the investigation'). That value may change depending on when we look at it.
For instance, take a simple rule which infers whether a person can obtain a driver licence:
the person can obtain a driver licence if
the person has passed a driving test and
the person's age is greater than or equal to 16
Imagine that we ran an investigation using this rulebase in 2006, and provided the information that the person had passed a driving test and was born on 1 January 1992. The rulebase would infer that the person can not obtain a driver licence, as they would not be 16 years of age. However, if we saved that interview and reopened it two years later (in 2008), it would immediately tell us that the person can obtain a driver licence, because they would be 16 years old. The interview was not altered - no new information has been given, and no existing information has been changed. Yet the value of some attributes have changed, due solely to the lapse of time.
Hence, an inherent property of every attribute is its value at a point in time. Oracle Policy Modeling allows you to write rules that reach conclusions based not only on values as they exist at a particular instant, but also based on how that value changes over time.
There are two ways in which a rulebase conclusion may change over time. The first is where the rule's outcome changes based solely on time. In this case, a conclusion can change even though the values of the rule's conditions have not. The age-based rule above is an example of this - different outcomes are reached at different times, even though the input data is always identical.
The second way in which conclusions might change over time is where the data that proves a goal itself changes. For instance, the interest rate of a bank account, or a legislatively-mandated amount of pension can change. As a result, other attributes that depend on this changeable data (eg the monthly amount of interest, the total pension payable) will also inherit different values as time passes. This differs from the age-based example above, because in this case, it is the change of information over time that dictates how the outcome value changes, not merely the passage of time by itself.
Oracle Policy Modeling includes a large number of functions to reason with the changing values of attributes over time. Some examples of rules that can be expressed are:
Temporal reasoning is used to handle three intersecting areas of change: changes in policy and rules, changes in rates and other reference data, and changes in circumstances. Common scenarios to watch out for include:
Policy and legislation are constantly changing. Business rules need to keep pace with that change if they are to be useful and accurate. Temporal reasoning functionality allows you to extend a rulebase's ability to cope with changing rules beyond what can be achieved by hard coded trigger dates alone.
For example, changing social security laws may lead to the introduction of a Government benefit, or a bank may implement a tough new policy for high risk debtors. In these cases, there are likely to be certain 'trigger dates' on which new parts of a rulebase need to become active. However, there may be calculations performed over time periods which overlap these dates, or new rules may apply to new clients in a different fashion than existing clients. Thus there is a need to write rules that can handle situations where both old and new rules may have a simultaneous role in reaching the overall conclusion. Temporal reasoning allows you to do this.
It is common for rulebases to feature reference data that is periodically changed. This data is generally kept either in the rulebase or an external database and is known at runtime (ie it is not user-entered data). Typically, these pieces of data take the form of rates (eg pay rates or interest rates) or thresholds (eg the minimum allowable pension payable, the monthly fee cap for a telephone plan). Oracle Policy Modeling allows you to make updates to reference data easily, while keeping deprecated or historical reference data intact. Temporal reasoning functionality then allows you to reuse a rule to calculate outcomes based on any time period, whether that period uses older, newer or a mix of reference data. Decision reports for outcomes that encompass changing reference data allow you to easily see the components of that calculation or result attributable to each reference data period.
In rulebases that calculate outcomes based on the circumstances surrounding a particular entity or group of entities (eg people, businesses), difficulties can arise when those circumstances change on a rapid (eg daily) basis. As an example, the total amount of money a health insurer pays to a customer may be dependent on the severity of the illness or injury, which can vary from day to day. Similarly, a government might pay an allowance that is affected by whether the recipient is co-habiting with someone else. If the recipient concerned is continually moving in and out of co-habitation status, it quickly becomes onerous to calculate the cumulative amount of allowance payable over, say, a year, unless temporal reasoning is used.
Temporal reasoning provides:
An inherent property of every attribute is its value at a point in time. Temporal operators are provided to tap into this property, including functions to calculate time-dependent items like:
These functions enable logic which is natural to a person to be captured in a readily understandable way, naturally handling conditions like the following:
How to model temporal rules is best illustrated with a worked example.
For this example, a pension payment is payable based on the following rules:
The business logic described above is captured in the following rules written in Microsoft Word:
the person's total entitlement for pension for the period = IntervalDailySum(the start of the period, the end of the period, the person's daily entitlement for pension)
| the person's daily entitlement for pension | |
|---|---|
| the standard daily rate of benefit |
the person is not married and the person satisfies the age requirement |
| the standard daily rate of benefit * 1.5 |
the person is married and the person satisfies the age requirement |
| 0 | otherwise |
|
the standard daily rate of benefit |
|
|---|---|
| 5 | TemporalBefore(2006-07-01) |
| 6 |
TemporalOnOrAfter(2006-07-01) and the person is not married |
| 7 |
TemporalOnOrAfter(2006-07-01) and the person is married |
| 0 | otherwise |
the person satisfies the age requirement if
both
TemporalBefore(2007-01-01) and
the person's age in years >= 55
or
both
TemporalOnOrAfter(2007-01-01) and
the person's age in years >= 65
the person's age in years = TemporalYearsSince(the person's date of birth, the current date)
Take a simple scenario, in which the person who will receive the pension:
- Is born on the 1st January 1950; and
- Was initially single, then married on 1 April 2007.
The assessment period is 1 January 2005 until 1 January 2020.
The person is assessed over a period from 1 January 2005 until 1 January 2020, generating the following timeline for the inputs:
| Date | Relevant Change | Type of Change |
|---|---|---|
| 1 January 1950 | The person is born | Circumstance |
| 1 July 2006 | Rate change for single/married people | Rate |
| 1 January 2007 | New rules for age criteria | Rules |
| 1 April 2007 | The person is married | Circumstance |
The inputs above generate the following results for the person. Note there is no change in result on 1 April 2007, as the person’s rate does not change on that date (they do not satisfy the age requirements).
| Date | Conclusion |
|---|---|
| 1 January 2005 |
The person turns 55 The person's daily entitlement for pension is $5 per day |
| 1 July 2006 | The person's daily entitlement for pension is $6 per day |
| 1 January 2007 | The person's daily entitlement for pension is $0 per day as they no longer satisfy the age requirements which have changed |
| 1 January 2015 | The person's daily entitlement for pension is $10.50 per day |